Bug: A race condition exists where the shared screenshot bitmap can be overwritten by the next frame's PixelCopy operation while the beforeStoreFrame callback is still processing it.
_{Severity: HIGH}

Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.

Location:
sentry-android-replay/src/main/java/io/sentry/android/replay/ReplayIntegration.kt#L314-L323

Potential issue: The `beforeStoreFrame` callback is passed a shared, mutable
`screenshot` bitmap that is reused across all frames. This callback executes on a
background thread, `replayExecutor`. Concurrently, the main thread schedules the next
frame capture, which uses `PixelCopy` to write to the same shared bitmap. There is no
synchronization between the `PixelCopy` write operation and the `beforeStoreFrame`
callback reading the bitmap. If the callback performs I/O, such as `bitmap.compress()`,
the bitmap's data can be overwritten by the next frame's data mid-read, leading to
corrupted images.

_{Did we get this right? 👍 / 👎 to inform future reviews.}

Correct, but that's already tracked here: #5340

I copied this from ReplayTest but why are we even running these on emulators in gh actions?

💯

not that it matters too much for tests, but that could be a set as well, right?

Correct, but that's already tracked here: #5340

h: Unless someone has asked for this callback, my vote would be for Internal rather than Experimental to avoid a footgun.

Eg, looks like we're hoping for read-only use cases, but we don't protect against writes, meaning users could modify the screens we save for session replay. And we lock on the bitmap after handing it off, meaning deadlock becomes a possibility (at least analytically). We could hand off a copy but I imagine we'd still want to recycle it after the callback completes to avoid memory issues, and that means warning the user accordingly. Etc.

Thoughts?

...looks like I was late to this game and we've updated to internal - good deal. (We should update the other sites to match 👍 )

l: Thoughts about keeping the nomenclature in line with our "screenshot recorded" language?

Eg, renaming BeforeStoreScreenshotCallback (if we want to guarantee the callback is fired immediately before writing to disk), or ScreenshotRecordedCallback (if we want to keep our options open about exactly when we invoke it) .

l: We could beef this up to protect against misuse if we think it'd help:

 * <p>**Bitmap lifecycle:** The bitmap is owned by the replay system. It should be deemed 
 * read-only and valid solely for the duration of the callback. Do not write to it or recycle it. Do
 * not synchronize on it, store a reference to it, or access it after this method returns – copy
 * the pixel data (e.g., compress to a file) within this method if you need it later.
 *
 * <p>The callback runs on a background thread (the replay executor).

...or whatever makes sense.